For the Ethernet access network to be able to deliver carrier-grade services, fast failure detection and failover time are becoming more and more important. After a failure is detected and data switched to alternative paths, there needs to be a mechanism to localize the failure in the network and then fix it.
Simple Network Management Protocol (SNMP), RFC1157, provides the trap mechanism for managed network elements to raise alarms to a management system when a failure occurs. SNMP traps are pre-defined events, among which for instance “link down” is one of the most common events defined by RFC1157 and supported by all vendors. When a link failure occurs, the managed network device associated with this link will issue a notification event to the management system. Upon receiving the event, the management system may choose to take some actions based on the event, for instance fixing the link failure, etc.
A newer approach specified by IEEE 802.1ag (“Draft Standard for Local and Metropolitan Area Networks—Virtual Bridged Local Area Networks—Amendment 5: Connectivity Fault Management”, IEEE 802.1ag, 2005) attempts to address the failure management, including failure localization, from layer 2. It provides both an architecture and working messages which are Layer-2 correspondence to IP Ping and TraceRoute. The essence of the 802.1ag architecture is in the nested management domains and the designation of maintenance endpoints and maintenance intermediate points. The nested architecture provides both an end-to-end view of the whole network along the service provisioning path and detailed responsible player of each hop of the network. Hence, when a link failure occurs, it is easy to address the failure on a layer-by-layer basis and reach the level where responsibility lies and actions have to be taken. Aside from the architecture itself, 802.1ag also defines four messages for information exchange and failure locating:
Continuity Check Messages:
These are “heartbeat” messages issued periodically by maintenance endpoints. They allow maintenance endpoints to detect loss of service connectivity among themselves. They also allow maintenance endpoints to discover other maintenance endpoints within a domain, and allow maintenance intermediate points to discover maintenance endpoints.
Link Trace Messages:
These are transmitted by a maintenance endpoint upon request of the administrator to track the path (hop by hop) to a destination maintenance endpoint. They allow the transmitting node to discover vital connectivity data about the path. It is similar in concept to IP Traceroute.
Loopback Messages:
These are transmitted by a maintenance endpoint upon request of the administrator to verify connectivity to a particular maintenance intermediate point or maintenance endpoint. Loopback indicates whether the target maintenance point is reachable or not; it does not allow hop-by-hop discovery of the path. It is similar in concept to ICMP Echo (Ping).
AIS Messages:
These provide asynchronous notification to other elements in the network that there is a fault in the metro Ethernet network. AIS is typically used to suppress alarms at network elements other than the ones that directly detect the fault.
In networks where nodes are interconnected via multiple paths the Spanning-Tree Protocol (STP) can prevent loops from being formed. This ensures that there is only one active path between any two network devices. The totality of active paths forms a so-called spanning tree. The Multiple Spanning Tree Protocol (MSTP) allows several VLANs to be mapped to a reduced number of spanning-trees. This is possible since most networks do not require more than a few logical topologies. Each tree can handle multiple VLANs that have the same topology. On this basis, a number of multiple spanning tree based fault tolerant architectures have been proposed.
As described by S. Sharama, K. Gopalan, S. Nanda, and T. Chiueh in “Viking: A multi-spanning-tree Ethernet architecture for metropolitan area and cluster networks”, IEEE INFOCOM 2004, the Viking architecture uses multiple spanning trees that are reconfigured after a failure event. The Viking Manager (VM) is notified via SNMP traps if a failure happens. VM then notifies the edge-nodes of the network that they have to redirect traffic to unharmed trees and initiates the recalculation and reconfiguration of the trees.
In contrast the low-cost resilient Ethernet concept is based on static spanning trees that are configured before network operation and do not change despite of failure occurrences (J. Farkas, C. Antal, G. Toth and L. Westberg, “Distributed Resilient Architecture for Ethernet Networks”, Proceedings of Design of Reliable Communication Networks, 16-19 Oct. 2005, pp. 512-522; J. Farkas, C. Antal, L. Westberg, A. Paradisi, T. R. Tronco and V. G. Oliveira, “Fast Failure Handling in Ethernet Networks”, Proceedings of IEEE International Conference on Communications, 11-15 Jun. 2006; J. Farkas, A. Paradisi, and C. Antal, “Low-cost survivable Ethernet architecture over fiber”, J. Opt. Netw. 5, pp. 398-409, 2006). In this architecture, failure detection and fault handling is implemented in a distributed manner in the edge-nodes. This architecture consists of low-cost off-the-shelf standard Ethernet switches available on the market; any solutions relying on new functionality in the Ethernet switches are excluded in order to keep the price advantage of current Ethernet products. The extra functionalities that are needed for providing resiliency are implemented as a software protocol at the edge-nodes of the Ethernet network.
FIG. 2 shows an example for such architecture. Predefined multiple spanning trees are statically set-up across the network to serve as either primary or alternative paths that can be used to route traffic in the network, thus able to handle possible failures. To achieve protection against any single link or node failure, the topology of the spanning trees must be such that there remains at least one complete functional tree in the event of failure of any single network element. Therefore the spanning trees have to be partially disjoint, i.e. they must comprise different network elements, they cannot be identical. For instance, spanning trees can be calculated. Multiple failures can be handled with more trees; it is a matter of tree design. The spanning trees are set-up before network start-up, remaining unchanged during operation, even in the presence of a failure.
In the event of a failure, each edge-node must stop forwarding frames to the affected trees and redirect traffic to unharmed trees. Therefore, a protocol is needed for failure detection and for notifying all the edge-nodes about the broken trees. Failover time mainly depends on the time elapsed between the failure event and its detection by the edge-nodes because protection switching from a tree to another is done without any re-configuration of the Ethernet switches.
The Failure Handling Protocol (FHP) is a simple and lightweight distributed protocol implemented in the edge-nodes that relies on few broadcast messages to provide fast protection against a single link or node failure occurred in the network.
The protocol basically defines three types of broadcast messages:                Alive: message sent out periodically by one or more edge-nodes referred to as emitter over each VLAN according to a predefined time interval TAlive;        Failure: message issued by an edge-node named notifier when an Alive message does not arrive over a VLAN within a pre-defined detection interval TDI, to inform all the other edge-nodes of a failure in that VLAN;        Repaired: message issued by the same notifier that detected a failure when an Alive message arrives over a previously failed VLAN to inform all the other edge-nodes about the reparation of the failed VLAN.        
Two types of notifiers are distinguished based on their timer settings: primary and secondary. Few notifiers are configured as primary; all the others that are neither emitters nor primary-notifiers are called secondary-notifiers. The reason of differentiating primary and secondary-notifiers is to reduce the number of concurrent notification messages during a failure event, as detailed below.
As shown in FIG. 3, Alive messages are broadcasted periodically by the emitter edge-node over each VLAN at the beginning of TAlive time interval. The requirement is that Alive messages are received on all VLANs at each other edge-node (notifier) within the predefined TDI time interval. As the transmission delay is, in general, different for each notifier and protocol time intervals are short, the synchronization of notifiers with respect to the emitter has key importance. Therefore, each notifier starts a timer when the first Alive message has arrived in order to measure when TDI has elapsed, i.e. the first received Alive message synchronizes the notifier to the emitter. Thus, the effect of the difference in transmission delay among different notifiers has been eliminated. Subsequent Alive messages suffer somewhat different delay as they travel different path, which has to be taken into account during the configuration of TDI. The arrival of all Alive messages is registered in each notifier edge-node. If there are Alive messages that have not arrived within TDI, then the corresponding VLANs are considered down. That is, the loss of a single Alive message is interpreted as the breakdown of a VLAN. However, to avoid false alarms due to an Alive frame drop, notifiers can be configured to wait two or three subsequent Alive periods and mark a VLAN broken only if Alive message is consistently missing in each period.
All edge-nodes, except the emitter, supervise the reception of Alive messages. However, to avoid excessive protocol load after a failure, there are only a few primary-notifier edge-nodes whose task is to notify other edge-nodes about the failure. The detection interval of primary-notifiers is shorter than that of secondary-notifiers, and it can be adjusted depending on the network size and other parameters. When a notifier edge-node detects a failure, it broadcasts a Failure message over each operating VLAN that is considered unharmed, which contains the IDs of the broken VLANs. As each edge-node receives the Failure messages, all of them become aware of the failed VLANs.
As the number of primary-notifiers is intentionally limited, some failures might be undetected depending on the network topology. Therefore, if a secondary-notifier detects a failure based on the missing arrival of an Alive message, then this node broadcasts the Failure message to inform all the other edge-nodes of the failure in the same way as described above.
SNMP and CFM based approaches have their limitations. For instance, SNMP is dependent on the proper functioning of IP, which is not always valid in layer-2 Ethernet access environment. SNMP traps can be used for fault localization as proposed for instance in the Viking architecture discussed above. However, there may be network nodes that are not able to send SNMP traps, e.g. non-manageable nodes, not configured or misconfigured nodes. In this case, fault localization cannot be solved by SNMP traps. 802.1ag is a relatively new standard and the mechanism specified is complex, and its effectiveness has not yet been proven. However, both SNMP and CFM based approaches have one problem in common: they lack the proper failover mechanism. Both solutions can identify when and where a link failure occurs, but neither of them has a complete solution as for how to lead the network to walk around the failure.